Startup times are an important performance attribute for nearly any computer application. Slow startup times and other performance delays cause irritation and inefficiency. In the case of middleware, the importance of startup time stretches far beyond a matter of perception. Middleware includes software that connects various computer applications across a network in order to exchange data. Disruption attributable to slow startup time in middleware often can lead to lost work, data and man hours.
Middleware is expected to be highly available, i.e., never have downtime or be unavailable. One way to improve an application's high availability rating includes decreasing its recovery time. Thus, decreasing startup time directly improves recovery time.
Delays in startup time is most conveniently identified and analyzed in terms of what defines them—elapsed clock time. As is the case of most applications, a startup log is used to obtain the best record of that which contributes to total wall clock startup time. However, these logs are limited in that they fail to identify startup specifics, making it difficult to isolate what needs to be changed to improve startup time. That is, system logs contain relatively high-levels of information and do not include the granularity needed by a programmer to effectively locate problems.
The granularity typically required by a programmer can sometimes be obtained using a profiler. A profiler comprises an algorithm that may be used to capture events and other statistical information about an executing program. The usual goal of profiling is to determine which parts of a program to optimize for speed or memory usage. The output of the profiler typically comprises a statistical summary of the events observed. Typical output, for instance, may relate to the frequency and duration of function calls. Profilers use a wide variety of techniques to collect data, including hardware interrupts, code instrumentation, operating system hooks, and performance counters.
Limitations of current profiling solutions, however, complicate efforts to optimize startup times and other performance attributes. While profilers can be indispensable in optimizing certain types of applications, profiles cannot easily be analyzed in terms of wall clock time. Conventional profilers basically report only the central processing unit (CPU) time, or cycles, required to execute a given piece of code. Profilers are incapable of expressing events in terms of a clock time. Unfortunately, applications such as startup time are measured in terms of wall clock time, which includes any program delay that may have occurred. This conventional limitation makes it hard to pinpoint in terms of wall clock time exactly how to decrease startup time. Programmers are consequently relegated to tedious and uncertain analysis that includes trying to manually locate and address problems based on clues in the log files. Finding the correlation by hand is often impractical because the exchange between the startup log time and the profile time is inexact.
The limitations of conventional profilers can be exacerbated in multithreaded environments. Such environments permit computer programs to concurrently execute in multiple threads so that multiple tasks can essentially be performed at the same time. Threads generally represent independent paths of execution for a program. In an e-commerce computer application, for example, different threads might be assigned to different customers so that each customer's specific e-commerce transaction is handled in a separate thread. The multithreaded nature of such applications compound the lack of correspondence between the profile data and output files. Processors switch back and forth between threads over a given period with such frequency as to further attenuate any link between CPU cycles and actual wall clock time.
Therefore, what is needed is an improved manner of analyzing startup time and other aspects of computer performance.